Fix VS Code Define Step never recovering after a post-open build - #26

Summary

• Closes VS Code: "Define Step" code action has no visible effect #2. The issue's own hypothesis — a bad WorkspaceEdit shape (flat changes map instead of documentChanges with CreateFile) — was tested and disproven: FeatureCodeActionHandler already sends the correct documentChanges/CreateFile/TextDocumentEdit shape, and it round-trips correctly through vscode-languageclient's real type guards and apply logic (verified with a raw wire capture, a standalone Node driver using the actual vscode-jsonrpc/vscode-languageserver-types packages against the real server, and a full VS Code Extension Host run that created the file with correct content end-to-end).
• The actual root cause: server-side binding discovery (ConnectorBindingRegistryProvider) reflects over a project's OutputAssemblyPath DLL. If that DLL doesn't exist yet when the VS Code extension's ProjectManager sends its first reqnroll/projectLoaded (e.g. a freshly cloned repo opened before ever running dotnet build), discovery fails once ("Output assembly not found") and is never retried. Visual Studio doesn't hit this because VsProjectEventMonitor hooks DTE's BuildEvents.OnBuildDone and re-sends every project after each build; the VS Code extension had no equivalent, so a user who opens the project, builds it, and then edits a feature file ends up with a permanently empty match cache — diagnostics, semantic tokens, and code actions for undefined steps all silently absent.

Revised fix (was: full reqnroll/projectLoaded resend)

The server already declares a standard workspace/didChangeWatchedFiles registration for **/bin/**/*.dll (WatchedFilesHandler.cs) specifically to retry discovery once the output assembly appears, resolving the owning project from the OutputAssemblyPath it was given at initial registration (that path is computed from MSBuild properties and is correct even before the file exists). Whether each IDE's LSP client actually delivers those dynamically registered watched-file events reliably is an open design question (Q9 in docs/LSP-IDE-Support-Open-Questions.md) — VS Code's files.watcherExclude commonly excludes bin//obj/ from the file watching a dynamically-registered FileSystemWatcherFeature relies on, which is the most likely reason this wasn't firing.

Rather than working around that by re-running dotnet msbuild and resending the full reqnroll/projectLoaded + reqnroll/projectFiles baseline on every rebuild (the original approach in this PR), ProjectManager's fallback watcher now sends the same standard workspace/didChangeWatchedFiles notification directly — landing on the server's existing handler with no new server code and no extra MSBuild invocation per rebuild. This is lighter weight and reuses the server's existing debounce/cancel-and-restart discovery logic instead of duplicating it client-side.

A follow-up issue tracks investigating and closing Q9 properly (confirming the exclusion-pattern hypothesis and deciding whether the dynamic-registration path can be made reliable enough to drop this client-side fallback entirely).

Test plan

• Added a unit test asserting bin/**/*.dll paths resolve to their owning project via the existing findOwningProjectFile helper.
• Manually verified end-to-end in a real VS Code Extension Host: with the fix reverted, a code action requested before a build stayed absent forever even after building; with the fix applied, "Define missing step" appears within ~20s of the build completing, applies correctly, and creates the populated step-definition file — all without restarting VS Code.
• Full LSP spec suite: 131 passed, 18 pre-existing skips, 0 failures (dotnet test tests/LSP/Reqnroll.IdeSupport.LSP.Server.Specs).
• npm run compile / npm run lint / npm test (VS Code extension unit suite): all clean, 17 passing.

🤖 Generated with Claude Code

• Not yet re-verified: the manual Extension Host build-then-code-action scenario was only run against the original (heavier) fix; it has not been re-run against this lighter-weight didChangeWatchedFiles revision. The automated unit suite passes and the logic change is small/mechanical (same trigger, same server-side handler, different message), but a manual re-run is recommended before merge.